Under the support of virtualization technologies, cloud computing can provide a scalable resource pool of computing, storage, and application services. A main development trend of cloud computing is to construct a network architecture having a high-capacity non-blocking data center, and various types of service applications can be supported on this basis. A network device needs to support a larger server cluster, migrate a virtual machine in a wider range when the virtual machine is applied, and ensure service continuity in a migration process. Therefore, cloud computing needs to meet the following three network requirements.
1. Non-blocking network architecture and multipath traffic balance.
Traffic characteristics of a data center (DC for short) are: Internal horizontal traffic (traffic between internal servers) is greater than vertical traffic (traffic between an internal server and an external client), and the internal horizontal traffic is highly bursty and cannot be planned beforehand. In a network architecture in a data center in the existing technology, a fat tree form tends to be adopted to construct non-convergence internal interconnection. In a fat tree network architecture, equal-cost multi-paths between nodes in the network need to be made good use of from a control layer to meet a non-blocking switching requirement, so that a problem of increasing horizontal traffic conflicts in the data center may be solved.
2. Adopt a large L2 (that is, data link layer, also referred to as layer 2) network to support a greater server cluster and virtual machine migration.
A traditional L2 technology cannot support multiple network paths, the utilization rate of a valid path of an entire network by the network after breaking loops by using a technology related to the Spanning Tree Protocol (STP for short) is very low, and a greater server cluster and a wider virtual machine migration range need a larger L2 network. A large L2 network can improve a migration range of a virtual machine and implement wide-range server sharing.
3. A public cloud requires a network to support a capability of identifying multiple tenants, so as to perform control over the tenants.
In construction of the public cloud, a huge number of service instances are required for identifying multiple tenants, and how to support more tenant services on a network device is also a problem. For example, a data center that includes 500K virtual machines needs a capability of supporting more than 10K service instances.
Currently, standard technologies of a large L2 network in a data center include: the Transparent Interconnection of Lots of Links (TRILL for short) technology of the Internet Engineering Task Force (IETF for short), and an 802.1aq technology of the Institute of Electrical and Electronics Engineers (IEEE for short). The basic principle of the two is: calculating shortest path first (SPF for short) of a layer-2 link at layer 2 according to a connection status of ports and links by using an Intermediate System to Intermediate System (ISIS for short), so as to obtain a cross-device shortest path. On a data plane, the two technologies adopt different encapsulation formats. The TRILL defines a TRILL header, and a layer-2 packet of a user is encapsulated in the TRILL header and forwarded hop by hop. The 802.1aq, that is, Shortest Path Bridging (SPB for short), uses a mac-in-mac (MacInMac) encapsulation format defined by 802.1ah, and defines a specific multicast header extension manner according to a protocol requirement, where an inner MAC of a MacInMac header is a layer-2 packet of a user. The two differ to some extent in a protocol control plane: A control plane of the TRILL protocol involves less calculation than the SPB, and meanwhile, use of network bandwidths can be balanced through a hop-by-hop equal-cost multi-path (ECMP for short); however, a current service instance of the TRILL protocol is an 802.1q virtual local area network (VLAN for short) identifier in a packet, where the identifier is 12 bits in total and there can be 4094 service instances at most, which limits the number of tenants that a public cloud can support. The SPB protocol mainly uses a service ingress to perform multipath load sharing, may plan service traffic globally and can support service instances of 16M. A control plane of the SPB protocol involves more calculation than the TRILL. In the TRILL protocol, a layer-2 packet of a user is encapsulated by using the TRILL header. The TRILL header includes a VLAN ID of a network transmission node (outer VLAN). ISIS routing calculation is performed according to the VLAN ID and in combination with an interconnected link. An intermediate node on a forwarding path performs selective learning according to whether the intermediate node has the service instance (with an inner VLAN encapsulated in a corresponding packet), and forwarding to a user port is performed at a destination node. The TRILL protocol is a process of equal-cost path routing for traffic scattered hop by hop on a forwarding path. In the SPB, a layer-2 packet of a user is encapsulated by using MacInMac encapsulation, and external BMAC+BVLAN are used to bear and forward the user packet between network devices, and a service identifier of the user is identified by an ISID (24 bits) in a specific I-TAG in the MacInMac header. The SPB performs forwarding learning according to MAC+ISID. A user packet may have multiple forms, including UN-TAG, single TAG, and dual TAG. On a forwarding plane of the SPB, different BVLANs form multiple equal-cost forwarding planes; and meanwhile, at a user access side, a mapping rule may be specified flexibly to map the user packet to a corresponding forwarding plane. Once a mapping relationship is specified at the ingress, the user packet arrives at its destination node device along an end-to-end fixed path determined through calculation. The biggest difference between forwarding behaviors of the SPB protocol and the TRILL protocol is: A forwarding path of the SPB protocol is determined in an end-to-end manner, its multipath loading sharing is subject to traffic allocation at the ingress, and traffic is mapped to different forwarding planes for sharing; while the TRILL protocol is a process of equal-cost path routing for traffic scattered hop by hop on a forwarding path.
Although the SPB protocol can provide more service instances (with a 24-bit ISID) to meet service requirements, a traffic model of load sharing of the SPB protocol is to perform fixed routing at the ingress. Compared with the TRILL protocol, the fixed routing manner of the SPB protocol cannot ensure maximum traffic load balance, the data center itself has much uncertain bursty traffic, and mapping can hardly be planned properly beforehand without a clear traffic model. Therefore, the SPB protocol is more vulnerable to a congested hotspot. Besides, in a case of network expansion for a data center with a fat tree architecture, the fixed routing of the SPB protocol easily leads to more ECMPs, and utilization of a valid path in the network is low when a path is planned in an end-to-end manner; while the TRILL protocol can better utilize a valid path in the network due to hop-by-hop shortest path distribution. In a fat tree network architecture, interconnected ECMPs of internal nodes continuously increase as the network scale increases (assuming that device capacity is constant), and it is increasingly difficult to make full use of network bandwidths by adopting the SPB protocol to calculate the fixed number of end-to-end paths; the hop-by-hop ECMP balancing manner of the TRILL protocol is obviously better.
In summary, although the hop-by-hop ECMP balancing manner of the TRILL protocol is obviously better, but the number of service instances is small and cannot satisfy more than 4K service instances. For example, it cannot meet a multi-tenant requirement from a public cloud.